In large-scale cable modem networks, data, voice and other services are delivered over an Internet Protocol (IP) network that uses coaxial cable or fiber optic cable or both for communication links. The cable modem and the computer connected to the modem reside on the customer premises rather than on the premises of the network service provider, and the modem and connected computer are called hereinafter customer premises equipment (CPE). In this context, CPEs become active and inactive regularly as users initiate and terminate use of network services.
For each CPE to operate on the network, the customer premises equipment undergoes configuration for network operations. For example, the IP addresses for the modem and computer are allocated, the particular customer who owns or rents the modem is identified, the services to which the particular customer has subscribed are identified and modem settings are specified to provide the subscribed services.
Configuring each CPE device is a tedious process to perform manually. It takes time to manually allocate IP address by selecting them from thousands of IP addresses that might be in use, to determine to which services of dozens of services one customer of tens of thousands of customers has subscribed and build a custom configuration file. A human loses concentration and is prone to make errors before successfully completing such tasks. A manual process would be expensive, non-scalable and not real-time.
Furthermore, it is impractical to configure CPE devices manually because they may request configuration every time they are rebooted. It is impractical for a network service provider to send a network administrator to the customer premises every time the cable modem is turned on; it is impractical to expect that the cable modem be on at all times; it is impractical to expect an ordinary user to be able to configure a device; and it is impractical to ensure that a customer who does configure the device manually has configured the device correctly and only for the services to which the customer has subscribed.
Consequently, a provisioning server is commonly provided for the network at the service provider's headend facility, where the cable links from a large number of customer premises terminate. The provisioning server responds to messages from the modem announcing the modem's connection to the cable network, performs various operations to determine parameter values that indicate modem settings and network properties, and sends the parameter values to the modem in one or more messages. Often, parameter values are included in a file that is identified in one or more messages to the modem, and, in response, the modem performs a file transfer to download that file and obtain the parameter values.
For example, in the Data-Over-Cable Service Interface Specification (DOCSIS), cable connections from customer premises terminate at the cable modem termination system (CMTS) located at the headend. The DOCSIS is available at the time of this writing on the Word Wide Web at domain scte.org in file SP-RF1-CO1-011119.pdf of directory /standards/pdf/webdocs/. Under DOCSIS, a cable modem (CM) uses the dynamic host configuration protocol (DHCP) to request configuration information, such as the IP addresses for the customer premises equipment. DHCP is an open standard protocol for dynamic host configuration described in request for comments (RFC) documents numbered 2131 and 2132, available at the time of this writing as rfc2131.html and rfc2132.html, respectively, on the World Wide Web (www) at domain ietf.org. The CMTS receives a DHCP request message and relays it to the provisioning server, which generates a DHCP response message. The DHCP response message includes the lease for an IP address to be used by the CPE, the location of the file with configuration parameters and other parameters. The cable modem uses the trivial file transfer protocol (TFTP) to download the configuration file from the provisioning server. TFTP is an open standard protocol for file transfer between different hosts, described in request for comments (RFC) document numbered 1350, available at the time of this writing as rfc1350.txt on the World Wide Web (www) at domain ietf.org.
However, this design poses some challenges. First, if the CMTS goes offline, all cable modems terminated by this CMTS have to go through configuration process equivalent to the one they do during reboot. This generates a considerable load on the provisioning server, which it must be able to handle efficiently. The provisioning system must be robust in the face of power outage at the cable headend.
Second, a similar or greater load on the provisioning server may be generated when a neighborhood is restored to power after a power failure. The provisioning server may have insufficient computing power on the headend device to handle all the configuration requests. Many CPE devices will have to wait too long to be configured and commence receiving network services. The more subscribers there are connected to a headend, the more severe the problem.
One approach is to define a static set of values for all configuration parameters for a particular CPE device so that computational resources are not excessively consumed when CPE devices come online. However, this approach is undesirable because it does not allow for a user to readily change the network services to which the user subscribes. Furthermore, a static approach is inconsistent with dynamic allocation of IP network addresses that is employed to conserve a limited number of IP addresses.
In addition, the static values approach is inconsistent with current techniques for ensuring the validity of configurations of certain network services. For example, DOCSIS provides for optionally including security data along with the configuration parameters for the customer premises equipment. The security data is sent with the values of the configuration parameters to the customer premises equipment. The customer premises equipment includes the security data with the request for network services sent to the CMTS. The CMTS uses the security data to verify the request. One example of such optional security data is the IP address assigned to the customer premises equipment. If this data is included it allows the CMTS to confirm the configuration parameters were intended for this device. Another example is the current time. If the time the provisioning server prepared the configuration parameters is included as security data, the CMTS can confirm the device is using a current set of configuration parameters. The IP address changes over time and is not static. The current time needs to be obtained each time the configuration parameters are supplied by the provisioning server. A set of static configuration parameters would not be able to include this non-static security data and support these important aspects of the DOCSIS security mechanism.
A variation on the static approach is to give static values for as many configuration parameters as possible for as many customers as possible, but to allow a limited number of parameters to have dynamically altered values. This approach has the advantage of being consistent with dynamically assigned IP network addresses and the security mechanisms of specific technologies.
Another approach is to provide several provisioning servers to share the load. For example, several DHCP servers are often made available to provide IP network addresses for devices that connect to a network. An advantage of this approach is that if one of the provisioning servers goes down, another provisioning server can provide the configuration data. Such an approach is more robust in the face of equipment failure. DHCP servers do not provide values for all the configuration parameters, such as the security mechanism parameters, used by DOCSIS.
The problem with multiple servers is that it is tedious for a network administrator to update the servers when configuration information changes. For example, if a user subscribes to additional services, such as greater download bandwidth for faster downloads, or voice over IP, the system administrator must log onto the multiple provisioning servers and make that same change repeatedly. It is likely that one of the entries may be made incorrectly or forgotten completely.
Based on the foregoing, there is a clear need for a dynamic configuration system that is scalable, in the sense that it can accommodate large numbers of customer premises equipments simultaneously requesting values for configuration parameters. There is also a need for a dynamic configuration system that is robust in response to equipment failure.
The past approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.